The manufacturing test flow has historically been challenged by the separation between the integrated circuit design and manufacturing test communities. Design engineers typically create test patterns for the design of an integrated circuit and send these to the test engineers. The test engineers incorporate these test patterns into an overall test program to be loaded into and executed by Automated Test Equipment (ATE). The automated test equipment generally comprises a computer software controlled tester in which a device under test is mounted. A number of ATEs are commercially available, many operating on different operating system platforms with different instructions sets and formats. Thus, the handoff between the design engineer and the manufacturing test engineer can be difficult because the test patterns must be translated into a format understood by the ATE. In addition, when failures occur, the test engineer often needs to consult with the design engineer and the device design data for proper diagnosis.
This communication and consultation between design engineers and test and production engineers is exacerbated because of strong dependence on specific commercial ATE architectures, their proprietary operating system and operational characteristics. In turn, this creates a manufacturing test environment that is extremely resource intensive and that significantly affects time-to-market, time-to-volume, and quality of an integrated circuit.
While embedded test architectures have been proposed that enables significant reduction of test vector and test program preparation for production go/no-go testing, no test result data is typically available for diagnostic analysis. The diagnosis issue is especially important when Built-In Self-Test (embedded test) is part of the test methodology. Since built-in self-test tests are self-contained, no test result data is typically available for diagnostic analysis beyond gross go/no-go reporting. Therefore, to obtain greater diagnostic resolution, the embedded test blocks must be run several times on a “batch” basis, with each run using different test patterns and/or embedded test operating modes to obtain additional diagnostic information. In many cases, the setup requirements for each embedded test run depend on the results of one or more of the previous runs. This means that the test engineer, or, more often, the design engineer cannot create test programs in advance to diagnose failures but must do so while the diagnosis is taking place.
In summary, there is a need for an generic test environment that is based on a seamless transfer and synthesis of information between design engineers and test and production engineers and which facilitates the development of test programs and the diagnosing test results.